One way to handle multi-line prototypes in arduino files #117
Conversation
…at the code for a tag is multiline (that is, there's no closing paren), use the Filename/Line info in the tag to attempt to read a few lines from the original code to hopefully get a better block of code to look for the prototype in.
|
While this does add a bunch of file i/o from a quick run of a few dozen apps here, it appears that most multi-line prototypes end up coming out of ino files, and the time overhead for this doesn't appear to be noticeable in my runs here. |
|
Hi @focalintent , this is a great news! Would you mind adding a test under ctags_parser_test.go to demonstrate the new functionality? |
|
Sure - it'll take a little bit for me to get one put together (first time messing with go at all - and also, because this fix involves reaching back into the original file mentioned in the file field of the ctags output to open it up to do the prototype finding/matching, I can't quite use the existing ctags parser test templates - though I think i'm getting a rough idea how to put together a test for it). |
|
Doing a test for this is a bit more complex - because the fix involves going back to the original input file the existing test case's plan of reading text from lines of ctags output isn't sufficient to test, and unfortunately, I'm about to take off for a couple of weeks, so I won't be able to get back to this until mid-march some time. |
|
Ah, saw how to do sketch/build tests - should be able to do that later tonight. |
|
@facchinm added a test case for this (sorry for the delay! new to go and the arduino-builder source) |
|
Rebased and merged as fbfaa56 |
A somewhat heavy handed way to deal with #80 if we detect that the code for a tag is multiline (that is, there's no closing paren), use the Filename/Line info in the tag to attempt to read a few lines from the original code to hopefully get a better block of code to look for the prototype in.